1. Field of the Invention
The present invention generally relates to modeling systems in order to perform processing functions such as, e.g., modeling, analysis, control, design, simulation, and management. More particularly, it relates to modeling dynamic or static systems by integrating models of intersecting or non-intersecting pieces of the system. Pieces of the system can be defined in a way that enables processing to be performed on individual models of each piece, and the results to be integrated into a system-wide result.
2. Description of Related Art
The present application relates to modeling dynamic or static systems, which can include, but are not limited to, enterprise management systems, engineering systems, networked information technology (IT) systems, utility systems, utility computing systems, autonomic computing systems, on-demand systems, electric power grids, biological systems, medical systems, weather systems, financial market systems, and business process systems. Such systems can be modeled for a variety of purposes including, e.g., monitoring, analysis, control, design, simulation, and management.
A model of a system is an abstract description of the system. The description will generally include sufficient details needed for the intended use of the model. For example, a model of a computer system may describe computers as having components such as processors, memory, disk, etc. They may further associate attributes with components, e.g., processor speed. Some models further include potential relationship between components, such as containment, connectivity, etc. to allow modeling the complex web of relationships in the real world.
Some models further include the semantics or meaning of the components and relationships. For example, the model of a processor may include specifying typical processor operations, or even typical processor problems, and the events each problem can cause.
Models are often expressed by using a formal specification that describes the characteristics of the components of the system, and the relationships between the components. Additionally, several paradigms can be used to describe the model. For example, an object-oriented paradigm can be used, in which the system components are modeled using objects, and relationships between components of the system are modeled either as attributes of an object; or objects themselves. Alternatively, a denotation paradigm can be used, in which the specification focuses on what the system does rather than how it operates. An operational paradigm can also be used, where the specification describes how the system operates. A database paradigm may specify entities and relationships. Furthermore, several different paradigms may be combined in any given specification.
Many formal languages are available for system modeling. In many cases, some languages will be more suitable than others depending on particular purpose of the model. These purposes can include, but are not limited to, documentation, design, analysis, reliability assessment, management, and simulation. The language used may be textual, e.g., Managed Object Definition Language (MODEL) available from System Management ARTS, Inc. of White Plains, N.Y., DMTF Common Information Model (CIM), Varilog, NS, C++, C, SQL, or graphical (e.g., state machines, VDHL, etc). Some modeling tasks may include different models of the same target system for different purposes.
Systems are conventionally modeled either as a monolithic whole or as divided into pieces, usually along the boundaries of its constituent subsystems. The description that follows on the related art will use subsystems as example of pieces of the system, but other possible divisions of the system into pieces are possible. Many times systems are modeled in order to perform some type of processing on the model reflecting some processing on the system. Complex models of complex systems are often too intricate to be effectively processed as a monolithic whole. If systems are divided into subsystems, known modeling methods fail to provide suitable techniques for dividing the system in a manner that enables processing to be performed on subsystems, and then results integrated into a system-wide result.
Such integration of processing results is difficult to achieve. This difficulty is further compounded when the system is dynamic, i.e., components/relationships are added/deleted/modified in real-time.
An example of a database system with several subsystems is shown in FIG. 1. The database system includes user client systems (e.g., a workstation at the user premises) connected to a Web server front-end at the service provider premises. The Web server in turn uses a load-balancing director to relay queries to several back-end databases servers. The connectivity between the client and the Web server can occur via a virtual private network or VPN while the connectivity at the service provider can occur through a local network.
Any system can, in theory, be modeled as a single monolithic whole. Such modeling can be performed using various modeling mechanisms, e.g., DMTF Common Information Model (CIM), which models a wide variety of objects of a distributed system; including applications, networks, systems, and organizations. (Common Information Model (CIM) Specification, Version 2.2. Distributed Management Task Force, Inc., Jun. 14, 1999).
Monolithic modeling, however, has many problems that increase the complexity of both representing the system and performing processing on it.
Firstly, the potentially large number of components may render the approach impractical. For example, an IT system with all of its hardware components, hosts, switches, routers, desktops, operating systems, applications, business processes, etc. may include millions of objects. It may be difficult to employ any manual or automated method to create a monolithic model of such a large number of components and their relationships. This problem is compounded by the typical dynamic nature of IT systems having frequent adds/moves/changes.
Secondly, there is no abstraction or hiding of details, to allow a processing function to focus on the details of a particular set of relevant components while hiding less relevant component details.
Thirdly, it may be impractical to perform any processing on the overall system because of the number of components involved.
The common approach is thus to divide complex systems into subsystems.
In the case of IT systems, there are several natural forms of dividing systems by following their architecture, e.g., along layers and/or tiers. But there are also many other different ways the same system can be divided into subsystems for different purposes.
In the example of FIG. 1, in which the system is divided into subsystems, the client subsystem model could represent the database service as one object without exposing all the internal details of the database service. This can be contrasted with the monolithic representation of all the myriad of components in the database service, including the service provider network nodes.
Several difficulties arise in processing subsystem models in a manner that enables integrating the results. Many of these difficulties stem from dependencies and relationships between the behaviors of objects that are assigned to different subsystem models. Changes to components in one subsystem may create propagated changes in other components in other subsystems. For example, if a node is added to the network, many relationships in the system, including the client-service ones, may have to change in order to reflect the addition of the new node. The same effects need to be reflected in the models of the respective subsystems.
It is difficult to separate the monolithic model into subsystems also because, e.g., several types of processing require understanding the overall system model. For example, fault management processing (the isolation of faults within a system) may require correlating events across many subsystem models because problems in one component often spread symptoms to related components in other subsystems, e.g., a problem in a network device may ultimately cause application transactions to time out.
Similarly, in provisioning an IT service, correctness depends on the properties of the infrastructure entities supporting the service. The natural split into subsystems would be to have separate subsystems for the service layer and for the underlying infrastructure. The division cannot ignore the inter-dependencies between subsystems. With respect to the database system of FIG. 1, the subsystems are inter-dependent or causally related because any behavior in one subsystem may propagate and generate behaviors in other subsystems and thus affect overall processing. For example, a VPN link failure event can generate a “database inaccessible” event at the client. Due to the overall system complexity, it is very difficult to understand what is happening in the system as a whole without understanding the relationships between the different subsystems.
As another example; referring to the example in FIG. 1, a degraded response time perceived by the client database query may be due to an ineffective load balancing director, which may be due to a malfunction of a database server in the cluster, which in turn may be due to a non-responsive interface event, which in turn may be due to a failed network connection event, which in turn may be due to broken VPN link connectivity as a result of a hardware problem at the service provider. The hardware problem is the root cause for all the events across multiple subsystems, including the database access failure event. The difficulty is that this analysis requires correlation processing of events across subsystem boundaries. No single subsystem in this example has enough data to identify the root cause.
It is also difficult to unify different levels of abstractions or different perspectives on the same components or their behavior. In other words, there can be difficulty in expressing behaviors in terms of components and relationships familiar to the subsystem, while hiding details of other subsystems. In the previous FIG. 1 example; from the perspective of the client, the root cause behavior is that the database is malfunctioning. From the perspective of the database service site, some VPN link is down. From the perspective of the VPN service provider, a specific hardware component failed. Each subsystem only has partial view of the whole system and may want to identify the root cause behavior using abstractions contained within the models of its specific components.
There can also be difficulty in capturing the meaning of a relationship between components in different subsystems. Subsystem relationships may need to include semantic information to aid in integrating processing across subsystems. For example, in FIG. 1, a database client is related to the database server through a transaction relationship. If a database server has problems, the transaction may or may not suffer. If the problem impacts performance, it will affect only transactions that have real-time response constraints. Only if the client-server relationship in the example is real-time, should the modeled server failure cause a performance impact on the client subsystem. The key information to accurately modeling of the system and its behavior is the meaning or semantics of the inter-subsystem relationships.
A need accordingly exists for an improved method and system for modeling systems.